需求管理 (项目)

需求管理(项目)(requirement mangement)

　　需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法，可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。有效的需求管理在于维护清晰明确的需求阐述、每种需求类型所适用的属性，以及与其他需求和其他项目工作之间的可追踪性。

　　需求管理活动包括：

　　(1)定义需求基线。

　　(2)评审需求变更并评估每项需求变更对软件产品的影响从而决定是否实施它。

　　(3)以一种可控制的方式将需求变更融人当前的软件项目。

　　(4)让当前的项目计划和需求保持一致。

　　(5)估计变更所产生的影响并在此基础上协商新的约定。

　　(6)实现通过需求可跟踪对应的设计、源代码和测试用例。

　　(7)在整个项目过程中跟踪需求状态及其变更情况。

　　1．需求管理的特定实践

　　需求管理包含5个特定实践，如图1所示。现简介如下。

　　图1　　需求实践示意图

　　①获得对需求的理解。在初步整理需求的基础上，项目小组和用户代表通过初步的分析讨论，对当前项目的需求达成共识，并在需求列表中作相应记录。

　　②获取需求承诺。通过项目参与者的书面承诺，建立各方或各项工作的基准。

　　③管理需求变更。维护变更历史，为调整与控制提供数据。

　　④在需求变更后维护对需求的双向可追溯性。从软件可维护性的角度提出管理要求。

　　⑤标识项目工作(包括计划和产品)与需求的不一致性。若发现不一致性，即启动纠正措施。

　　2．需求管理的管理流程

　　上述5个特定实践，可归结为以下3项活动，即需求确认、需求跟踪和需求变更。

　　(1)需求确认包括图1中第1、2两个特定实践。由开发方和客户共同对主要需求文档“软件需求规格说明书”进行评审，双方达成共识后作出书面承诺，使需求文档具有商业合同效力。

　　由此可见，需求确认实际上包含了两个重要工作：需求评审和需求承诺。其中需求承诺是双方对通过正式评审后的“软件需求规格说明书”作出的共同承诺。承诺书的格式如下：

　　本“软件需求规格说明书”是建立在双方对需求的共同理解基础之上的，我们同意后续的开发工作根据该“软件需求规格说明书”进行。如果需求发生变化，
我们将按照“需求变更流程”执行，即需求的变更将导致双方重新协商成本、[[资源]]和进度等。

　　项目经理签字　　　　[[客户]]或客户代表签字

　　

　　该承诺书将附在“软件需求规格说明书”后，一同存档保存。

　　(2)需求跟踪

　　包括图1的第4、5两个特定实践，即维护对需求的双向可追溯性和标识项目工作与需求的不一致性。

　　为了有效地检验最终软件产品能否满足所有需求，对项目的需求要进行跟踪管理。跟踪的目的，是建立与维护“需求一设计一编程一测试”之间的一致性，确保所有工作成果都符合用户需求。为此可采用需求大纲中的需求跟踪矩阵，对每个需求追踪到实现该需求的设计、编码以及测试案例，从而验证该软件产品是否实现了所有需求，是否对所有需求进行过测试。

　　需求变更要进行控制，严格防止因失控而导致项目混乱，出现重大的风险。

　　1．需求变更的利弊

　　随着项目的进展，用户和开发方对需求的了解越来越深入，原先的需求文档很可能存在错误或不足。另一方面，市场会发生变化，原先的文档也可能跟不上当前的市场需求。可见需求变更总是不可避免的，有些是为了修正缺陷，有些属于增强功能。

　　对项目开发小组而言，变更需求通常意味着要调整资源、重新分配任务，并修改前期的工作成果，有时要付出较大的代价。如果动不动就变更需求，某些项目也许永远不能按时完成。为此，需求变更必须遵守利大于弊的原则，并做到：

　　①为避免出现失控等风险，对纳入基线以前的需求文档，可通过正常的check—in和check—out进行更改。而纳入基线以后的需求文档，更需按照预定的变更控制规程，确保快速、顺利和有序地进行变更。

　　②遵照如图2所示的需求变更流程来处理。下文将具体介绍这一流程。

　　图2 需求变更流程

　　2．需求变更的流程

　　需求变更通常按变更申请一审批一更改一重新确认的流程进行。

　　(1)变更申请

　　此时的状态为“请求变更”。首先由申请人提交需求变更申请书，其内容应该包括：

　　①变更源类型。指引起变更的原因类型，可分为需求变更、设计变更、代码优化、用户文档优化和计划变更等。②变更优先级。依据变更的重要性、紧迫性和对关键业务的影响程度，以及对系统安全性和稳定性的影响程度，可分为critical、high、middle和low等4级。

　　③变更标志。分为新增、修改和删除。

　　④变更影响分析。包括变更影响的工作产品和负责人，对工作量和进度的影响，发生风险的可能性与影响程度，以及需要回测的范围。

　　⑤可能影响的工作产品。包括项目计划、需求文档、概要设计文档、详细设计文档、源代码和程序、测试计划和测试案例以及用户文档。

　　上述申请书应由项目经理进行评估，其内容包括：

　　①该需求变更在技术上是否可行。

　　②对工期、成本、质量的影响。首先评估单个模块工期的影响，即实现该需求变更需要的成本和工作量；然后评估实现该需求变更对整体工期工作量和成本的影响。

　　(2)变更审批

　　按照影响的大小由不同的负责人审批。

　　①对影响小的变更，由项目经理直接审批。

　　②对影响大的变更，提交软件变更控制委员会(Sottware Change Control Board，SCCB)审批。

　　③项目SCCB仍无法决定的变更，再提交高层SCCB决定。

　　所谓影响大的变更一般包括下列情况：

　　①变更影响的模块数超过10个或超过50％，或者可能影响软件系统的框架。

　　②变更会影响对客户的承诺。

　　③变更会带来“高”或者“高中”程度的风险。

　　如果审批请求未通过，则该变更请求结束。

　　(3)变更修改

　　如果需求变更已审批通过，应指定相关的责任人对产品进行修改，并指定人员对更改后的产品进行审核。还应在产品列表中记录具体修改的产品名称、修改描述和是否完成修改的状态。包括：

　　①应及时更新相应的需求大纲和需求分析说明。

　　②如果影响项目计划的内容，修改项目计划，以反映需求的变更。

　　③如果影响到概要设计文档、详细设计文档、源代码和程序、测试计划和测试案例或者用户文档，它们也需要被及时更新。

　　④如果影响到测试，还需要进行回归测试。

　　⑤如果对文档进行修改，需在修改历史表格中注明修改人、修改时间以及修改原因。

　　⑥如果对原文件修改过大，必要时项目经理可以重新组织工作产品的评审。

　　⑦如果对代码进行修改，需要导出编译申请表，通知编译和测试。

　　(4)变更关闭

　　如果修改后不需要进行测试，则当所有产品全部修改完成时，由最后完成修改的人关闭该变更。如果变更修改后提交测试，则由测试人员负责该变更是否最后关闭：

　　①如果测试未通过，则返回修改者继续修改。

　　②如果所有工作产品全部修改完成，并且测试通过，关闭该变更。

　　图3为需求变更的状态转换图，从中可看到各种需求变更状态的转换。

　　图3　　需求变更状态转换图

　　3．需求变更的数据项

　　为了确切记录需求变化，还需登记如表1所示的变更数据列表。

　　在软件规模很小的时候，人们采用文档文件的方式来存储软件需求规格说明书和其他文档。在一些小规模的软件系统开发中，人们也还这样做。但是，随着各种计算机应用系统越来越复杂，软件规模也越来越庞大。这时传统的基于文档文件存储需求的方式越来越显露出它的局限性，主要体现在：

　　①手工维护大量文档文件十分困难。

　　②很难保持文档与现实的一致。

　　③通知受变更影响的设计人员是手工过程。

　　④不太容易做到为每一个需求保存附加的信息。

　　⑤很难在功能需求与相应的用例、设计、代码、测试和项目任务之间建立联系链。

　　⑥很难跟踪每个需求的状态。

　　⑦异地协作开发变得很困难。

　　随着软件工程技术的发展，需求管理的任务越来越繁重，迫切需要研制需求管理工具来自动化地管理需求，提高工作效率。IBM Rational RequisitePro、Telelogic DOORSreg和Borland CaliberRM等都是目前比较流行的需求管理工具，可以帮助开发团队有效地管理软件需求。

• 需求管理（供应链)